Norma para nuevos desarrollos cloud-native

Ámbito de aplicación de la norma

La Junta de Andalucía tiene como objetivo estratégico el despliegue de sus sistemas bajo un modelo de ejecución en nube híbrida, denominada Nube Corporativa de la Junta de Andalucía (NCJA), que proporcionará una infraestructura segura y escalable para maximizar los beneficios del modelo en nube: escalabilidad, flexibilidad y menores costes.

Por lo tanto, para facilitar el despliegue en nube, a todos los desarrollos de nuevas aplicaciones y nuevos sistemas de información que se creen en la Agencia Digital de Andalucía, se le debe exigir las siguientes normas generales Cloud-Native.

Diseño

Código fuente

DIR_01 Gestión del código fuente

OBLIGATORIO El sistema deberá gestionar su código fuente mediante mecanismos que permitan controlar los cambios y etiquetar versiones completas.

DIR_02 Relación entre código base y componente

OBLIGATORIO Cada sistema o componente deberá tener una relación unívoca con su base de código.

Cada entidad desplegable o reutilizable, como una librería, un componente web o un servicio, deberá disponer de su propio repositorio y evolucionar de forma independiente.

DIR_03 Generación de un único proceso ejecutable

OBLIGATORIO Cada entidad desplegable deberá generar un único proceso ejecutable.

Esto facilita la escalabilidad, la portabilidad, la monitorización y el desacoplamiento entre componentes.

Dependencias

DIR_04 Declaración explícita de dependencias

OBLIGATORIO No se permitirán dependencias implícitas sobre librerías o componentes del sistema operativo.

Todas las dependencias deberán declararse de forma explícita en el manifiesto o descriptor correspondiente al gestor de dependencias utilizado.

DIR_05 Uso exclusivo de dependencias necesarias

OBLIGATORIO La solución deberá incluir únicamente las dependencias necesarias para su funcionamiento.

Deberán eliminarse dependencias no utilizadas, innecesarias, obsoletas o con versiones incompatibles.

DIR_06 Aislamiento de dependencias en ejecución

OBLIGATORIO Las dependencias deberán estar aisladas en tiempo de ejecución para evitar efectos no controlados sobre otros componentes del sistema.

El aislamiento podrá realizarse mediante instalación local, herramientas específicas de aislamiento o contenedores.

DIR_07 Independencia de herramientas instaladas en el sistema operativo

OBLIGATORIO La aplicación no deberá depender de herramientas instaladas previamente en el sistema operativo del entorno de ejecución.

Configuración

DIR_08 Inmutabilidad de los artefactos

OBLIGATORIO Los artefactos que se despliegan deben ser inmutables e independientes del entorno. No se permitirá la entrega de artefactos cuyo binario cambie según el entorno de despliegue.

DIR_09 Externalización de la configuración

OBLIGATORIO Los artefactos no deberán contener configuración dependiente del entorno.

La configuración deberá inyectarse antes de la ejecución o durante el arranque de la aplicación. Se permitirá incluir configuración dentro del artefacto siempre que se garantice la inmutabilidad del binario en los diferentes entornos.

DIR_10 Separación entre configuración y código

OBLIGATORIO Los valores que puedan variar entre entornos deberán almacenarse fuera del código fuente y fuera del artefacto desplegable.

Entre estos valores se incluyen, al menos:

• URL de recursos.
• Credenciales.
• Nombres de servicios.
• Parámetros específicos de entorno.
• Certificados o archivos de configuración.

DIR_11 Mecanismos permitidos de configuración

RECOMENDADO La configuración podrá proporcionarse mediante alguno de los siguientes mecanismos:

• Variables de entorno.
• Volúmenes externos.
• Herramientas de configuración centralizada o dinámica.
• Servicios de configuración compatibles con la arquitectura de la solución.
• Perfilados de aplicaciones siempre que se garantice que el paquete entregado es el mismo para todos los entornos
   

Backing services

DIR_12 Tratamiento homogéneo de servicios externos

OBLIGATORIO Los recursos consumidos por la aplicación a través de la red deberán tratarse de forma homogénea, sin diferenciar en el diseño si son locales, corporativos o de terceros.

Se consideran backing services, entre otros:

• Bases de datos.
• Sistemas de mensajería.
• Colas.
• Servicios SMTP.
• Sistemas de caché.
• Servicios externos consumidos mediante red.

DIR_13 Acceso a recursos mediante localizador y credenciales

OBLIGATORIO El acceso a los recursos externos deberá realizarse mediante un localizador, como una URL o mecanismo equivalente, y las credenciales necesarias cuando aplique.

Esta información deberá gestionarse como configuración externa y no deberá incluirse en el código fuente.

DIR_14 Persistencia de ficheros fuera del sistema local

OBLIGATORIO La aplicación no deberá utilizar el sistema de archivos local como mecanismo de persistencia.

Cuando sea necesario persistir información en ficheros, se deberán usar recursos externos, como volúmenes acoplables, almacenamiento distribuido o servicios compatibles con la tecnología utilizada.

DIR_15 Integración con otros sistemas mediante APIs

OBLIGATORIO La integración con otros sistemas deberá realizarse mediante APIs.

No se permitirá la integración basada en acceso directo a bases de datos, intercambio directo de ficheros compartidos u otros mecanismos que acoplen internamente los sistemas.

Construcción

Ciclo de vida del software

DIR_16 Separación entre construcción, distribución y ejecución

OBLIGATORIO El ciclo de vida del software deberá separar claramente las fases de construcción, distribución y ejecución.

La construcción generará el artefacto ejecutable a partir del código fuente y sus dependencias.
La distribución combinará el artefacto construido con la configuración del despliegue.
La ejecución arrancará los procesos correspondientes en el entorno de destino.

Servicios autocontenidos 

DIR_17 Servicios autocontenidos

OBLIGATORIO El sistema deberá ser autocontenido y no depender de un servidor web o servidor de aplicaciones externo ya existente para exponer servicios públicos.

Las aplicaciones deberán incluir los componentes necesarios para ejecutarse de forma autónoma en el entorno cloud-native.

Procesos

DIR_18 Procesos sin estado

OBLIGATORIO Los procesos deberán ser sin estado y no deberán depender del resultado de peticiones anteriores.

Cualquier información que requiera persistencia deberá almacenarse en un backing service con estado, como una base de datos o sistema equivalente.

DIR_19 Prohibición de afinidad obligatoria entre sesión y proceso

OBLIGATORIO No deberán utilizarse sticky sessions ni mecanismos que obliguen a que una petición sea atendida por la misma instancia de proceso que atendió peticiones anteriores.

Cuando se necesite mantener información de sesión, deberá utilizarse almacenamiento externo, mecanismos de caché compartida o almacenamiento seguro en cliente, según proceda.

DIR_20 Diseño para concurrencia y escalado horizontal

OBLIGATORIO Las aplicaciones deberán diseñarse para poder dividirse en componentes ejecutables independientes y escalar mediante múltiples instancias.

DIR_21 Compatibilidad con múltiples réplicas

OBLIGATORIO No se permitirá el despliegue de aplicaciones que presenten errores o comportamientos inconsistentes al ejecutarse con dos o más réplicas.

El diseño deberá contemplar el acceso concurrente a recursos compartidos, sesiones, cachés y bases de datos.

Ejecución y operación

Desechabilidad

DIR_22 Procesos desechables

OBLIGATORIO Los procesos deberán poder iniciarse y finalizarse en cualquier momento sin comprometer la consistencia del sistema.

DIR_23 Reducción del tiempo de arranque

OBLIGATORIO Los procesos deberán minimizar su tiempo de arranque.

En soluciones basadas en contenedores, deberán seguirse las buenas prácticas vigentes para generar imágenes ligeras y eficientes.

DIR_24 Gestión ordenada de señales de finalización

OBLIGATORIO Los procesos deberán gestionar adecuadamente las señales de finalización.

Cuando un proceso reciba una señal de parada, deberá finalizar de forma ordenada, completar o devolver el trabajo pendiente y respetar los tiempos máximos definidos.

DIR_25 Preparación ante finalizaciones inesperadas

OBLIGATORIO Los procesos deberán estar preparados para interrupciones inesperadas.

La solución deberá adoptar las medidas necesarias según el impacto funcional o técnico de una interrupción.

Igualdad entre desarrollo y producción

DIR_26 Equivalencia entre entornos

RECOMENDADO Los entornos de desarrollo y producción deberán ser lo más equivalentes posible.

Se deberán utilizar herramientas, tecnologías y procesos de despliegue similares para reducir riesgos en fases posteriores.

DIR_27 Pruebas automatizadas

RECOMENDADO Se deberán utilizar pruebas automatizadas para validar la calidad del código y reducir diferencias entre entornos.

DIR_28 Coherencia tecnológica entre desarrollo y producción

RECOMENDADO Durante el desarrollo se deberán utilizar tecnologías equivalentes a las previstas en producción.

Por ejemplo, no se debería desarrollar contra una base de datos diferente a la prevista en producción si dicha diferencia puede alterar el comportamiento de la aplicación.

Logs

DIR_29 Escritura de logs en salida estándar

OBLIGATORIO Los logs deberán escribirse en la salida estándar o en la salida estándar de error.

La recolección, agregación y explotación de los logs deberá delegarse en los mecanismos de observabilidad y recolección del entorno.

DIR_30 Normalización del formato de logs

OBLIGATORIO Los mensajes de log deberán tener un formato normalizado que facilite su análisis, búsqueda y explotación.

El formato recomendado será:

YYYY-MM-DD | HH:mm:ss.SSS | LOGLEVEL | ApplicationName | Message

Donde:

• YYYY-MM-DD HH:mm:ss.SSS: fecha y hora de generación del evento.
• LOGLEVEL: nivel del mensaje.
• ApplicationName: nombre del sistema o componente.
• Message: descripción suficiente para diagnosticar la situación o conocer la acción realizada.

DIR_31 Niveles de log

OBLIGATORIO Los niveles de log deberán utilizarse de forma coherente:

• ERROR: errores que afectan al funcionamiento, aunque la aplicación pueda continuar.
• WARN: situaciones anómalas que no impiden el funcionamiento.
• INFO: información relevante de ejecución.
• DEBUG: información para depuración, no activa en producción salvo causa justificada.
• TRACE: información de máximo detalle para diagnóstico.
   

Procesos de administración o mantenimiento

DIR_32 Ejecución de tareas administrativas como procesos de una sola ejecución

OBLIGATORIO Las tareas de administración o mantenimiento deberán ejecutarse como procesos de una sola ejecución.

Se incluyen, entre otros:

• Migraciones de base de datos.
• Consolas o procesos de inspección.
• Scripts de mantenimiento.
• Correcciones puntuales de datos.

DIR_33 Ejecución en entorno equivalente a producción

OBLIGATORIO Los procesos de administración y mantenimiento deberán ejecutarse desde un entorno equivalente al de producción.

DIR_34 Asociación a una distribución concreta

OBLIGATORIO Los procesos de administración y mantenimiento deberán asociarse a una distribución concreta de la aplicación.

Deberán utilizar el mismo código, la misma configuración y el mismo modelo de gestión que el resto de procesos de esa distribución.

Versiones

Versión actual: v01r00

• Fecha de aprobación: 10/03/2023.